Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/opstat/opstat-minutes-92nov.txt

Text File | 1993-02-17 | 9KB | 219 lines

Editor's Note: Minutes received 12/7/92

CURRENT_MEETING_REPORT_


Reported by Henry Clark/OARnet

Minutes of the Operational Statistics Working Group (OPSTAT)

Agenda


   o Review of Client-Server Specification.
   o Resource Utilization Criteria.
   o Milestones/Goals Review.
   o Statistical MIB.


Client-Server Protocol

Bernhard reviewed the client-server paper sent to the mailing list
several weeks ago.  The commands within the protocol include:

    1)  LOGIN <username> <password>
    2)  HELP <object>
    3)  LIST <object>
    4)  EXIT
    5)  SELECT <rtr> <intf> <variables> FROM <sdate> to <edate> AT <gran>
          WITH <cond>

    Discussion started with the SELECT statement.  Should the variables
    specified be an actual router / interface name or a symbolic name?
    Should it be a list of variables or just a single variable?
    Consensus was reached to make it consistent with the RFC storage
    format document so that the select statement became:

    SELECT <networkname> <routername> <linkname> <variables> FROM ...

    Discussion then started on what the variable part should be.  Should
    it be a list of variables, and if so, in what format should it be
    in?  Again, we reached consensus to make it consistent with the RFC
    so that the SELECT became:

    SELECT <networkname> <routername> <linkname> TAG <tagname> FROM ...

    Some discussion then centered around where the select processing
    should be done.  For example, should the conditionals be processed
    on the server or client?  We agreed to discuss this later in the
    session.

    The <sdate> and <edate> fields of the FROM and TO parts of the
    SELECT were agreed to be in UTC, as in the RFC.  Some questions were
    brought up about how to handle the <gran> parameters.  We agreed
    that if the <gran> value didn't match the value in the database on
    the server, the server should return an error.  We also agreed to
    discuss later an expanded version of the LIST command to determine
    available granularities.

    Discussion continued for a time about the conditional part (WITH)
    for the SELECT statement.  We agreed that under certain querying
    conditions (such as "fetch all days with errors above X") great
    economies could be realized about by processing the conditional on
    the server versus downloading all data to the client and processing
    it there.  At other times, processing on the client would be a win.
    We agreed to leave the conditional processing on the server noting
    that the computations of conditions may be occasionally complex.

    Discussion then turned to how to fetch multiple occurances of router
    interface variables, such as SNMP get-next works.  We agreed to
    allow the SELECT format:

    SELECT * * * TAG <tagname> FROM...

    so that all instances of a particular interface, router, or network
    could be retrieved with one select transaction.

    We then debated whether we needed the keywords "min" and "max" in
    the <cond> part of the select?  We were unable to exactly define
    what a minimum for a period of time meant, particularly when data
    was aggregated to different values.  We decided that the server
    should not compute different granularities on the fly (i.e. if
    different granularities exist, then we shouldn't try to make them
    the "same").

    Some discussion revolved around the SQL-ness of the select command.
    We agreed not to make it more complex than it already was :-).

    The HELP command was removed since the protocol was not designed to
    be used directly from, say, telnet and other HELP commands (such as
    in SMTP) weren't implemented widely.

    Discussion continued on Section 3.2 (Net Names) of the draft
    client-server document.  We agreed that this section isn't
    meaningful anymore (this defines an ascii file containing backbone
    point-to-point links along with other information including
    bandwidth) since this information is included in the data files in
    the database.

    More discussion resumed on the conditional part of the SELECT
    statement (as defined in 4.4, as amended).  We all felt that the
    conditional should be kept as simple as possible, and felt that no
    added complexity was needed at this time (no sql :-)).

    In the draft document in Section 4.4 some mention is made of using
    CMIP distinguished names.  We all moaned in unison and agreed this
    was a bad thing (tm).

    After the break, discussion resumed on the syntax and semantics of
    the LIST command.  Originally, the LIST command was of the form:

    LIST <objname>

    In order to give it the added capabilities to list things like
    available tags and characteristics of those tags so that the SELECT
    statement can be formatted correctly, the format:

    LIST <network> <router> <interface> <tag> <date>
    was suggested.  An alternate method of using the command by placing
    "*" in certain fields would allow the retrieval of information about

    a given object.  The table below shows the information to be
    displayed:

    netname:       display all routers
    routername:    display all interfaces
    interface:     display all tags
    tag:           display all variables within a tag
    date:          display all available dates for a tag

    The output from such a list might be of the form:

    <network> <router> <interface> <tag> <dates> [ <tag> <dates> ]

****    We agreed that this should be specified in more detail later.


Resource Utilization Criteria

The question has arisen before of the issues surrounding link
utilizations and when a link should be upgraded and how to determine
``fair'' usage of a link by multiple organizations.

In terms of monitoring link usage, some networks query routers very
frequently (as often as every 60 seconds) to detect peaks.  Others try
to track IP src/dest address pairs to track traffic flows.  Some
networks attempt to monitor usage at various points around their network
to capture traffic flows.  Some mention was made of an accounting mib
such that traffic usage patterns could be withdrawn automatically via
MIB queries.  Some queries were to be made to the Internet Accounting
Working Group to determine the relevance of their work to this topic.

There was an extended discussion on when to ``upgrade'' a link.  When is
it full?  Should a link always run at max utilization in order to get
maximum $$ from a link?  Some mention was made of looking at the peak
values, the duration of the peak values, the number and distribution of
the peaks, and attempting to correspond the peak values to other events
on the router such as errors and packet drops.

Bernhard felt that this topic should be moved from the Operational
Statistics Working Group to another working group within the Operational
Area.  This was to be taken up at the ORAD meeting later in the week.

Goals & Milestones/Statistical MIB

The Common Storage Format RFC was submitted to the RFC editor in early
November 1992.  The initial re-examination of the client-server protocol
has been completed.  After some lengthy discussion, we moved the
completion of the client-server Internet-Draft to the July 1993 IETF
(with continuing discussions on the mailing list and at the March 1993
IETF in Columbus) and the completion of the Statistical MIB
Internet-Draft to the March 1994 IETF with a first draft ready at the
November 1993 IETF. Included in the discussions of dates was a
discussion of the future SMP stuff and the get-bulk retrieval mechanisms
for retrieval of data via the MIB which are to be examined in the
future.



                                   2





Attendees

Tony Bates               [e-mail]
Rebecca Bostwick         [e-mail]
J. Nevil Brownlee        [e-mail]
Henry Clark              [e-mail]
Michael Conn             [e-mail]
John Curran              [e-mail]
Hans Eriksson            [e-mail]
Dennis Ferguson          [e-mail]
Richard Fisher           [e-mail]
Peter Ford               [e-mail]
Phillip Gross            [e-mail]
Robert Gutierrez         [e-mail]
Eugene Hastings          [e-mail]
Alisa Hata               [e-mail]
Daniel Karrenberg        [e-mail]
Mark Knopper             [e-mail]
Daniel Long              [e-mail]
Kim Long                 [e-mail]
Bill Manning             [e-mail]
Dennis Morris            [e-mail]
David O'Leary            [e-mail]
Andrew Partan            [e-mail]
Marsha Perrott           [e-mail]
Bernhard Stockman        [e-mail]
Marten Terpstra          [e-mail]
Evan Wetstone            [e-mail]
Chris Wheeler            [e-mail]
Paul Zawada              [e-mail]



                                   3